THE LAN TUTORIAL SERIES

PART 3: (PROTOCOLS: continued)

Data Link Protocols
As we said last month, the IEEE protocol standards are not
confined to the Physical layer but also work at the Data Link
layer. We also said that the Data Link layer is often divided
into two parts. The upper part is called Logical Link Control
(LLC) and the lower part is called Medium Access Control (MAC).
As it turns out, the IEEE standards define the lower, or MAC,
half of the Data Link layer -- the part that determines how
network users keep from bumping into each other.

Medium Access Control is just what it sounds like. It is the
protocol that determines which computer gets to use the network
cable when many computers are trying. We saw that IEEE 802.3 lets
everyone simply bump into each other and keep trying until they
get through. IEEE 802.4 and 802.5 are more ordered, limiting
conversation to the computer with the token. Remember, all of
this is done in fractions of a second. So even when the network
is crowded, no one really waits very long for access on any of
the three types of networks.

The other half of the Data Link layer, LLC, provides reliable
data transfer over the physical link. In essence, it manages the
physical link.

There are two reasons why the IEEE split the Data Link layer in
half (and why the ISO accepted it). First of all, the Data Link
layer has two jobs to do. The first is to coordinate the physical
transfer of data. The second is to manage access to the physical
medium. Splitting the job allows for more modularity, and
therefore flexibility.

The second reason also has to do with modularity, but in a
different way. The type of Medium Access Control has more to do
with the physical requirements of the network than actually
managing the transfer of data. In other words, the MAC layer is
"closer" to the physical layer than the LLC layer. By splitting
the two, it is possible to create a number of MAC layers
(corresponding to physical layers) and just one LLC layer that
can handle them all. This increases the flexibility of the
standard. It also gives LLC an important role in providing an
interface between the various MAC layers and the higher-layer
protocols.

By the way, Logical Link Control is the more common name of the
IEEE's 802.2 specification. The numbers give it away. 802.2 works
with 802.3, 802.4 and 802.5. It should also work with emerging
standards, like FDDI.

There are other protocols that perform the LLC functions.
High-level Data Link Control (HDLC) is the protocol from the ISO.
Like LLC, it conforms to the OSI model. IBM's SDLC (Synchronous
Data Link Control) is a Data Link layer standard that does not
conform to the OSI Model but does perform similar functions. IBM
has many products that do not follow the OSI Model or its
hierarchical setup. IBM has pledged support of OSI, however.

Transport Protocols
The ISO is in the process of establishing protocol standards for
the middle layers of the OSI Model. As of yet, none of these have
been implemented on a widespread basis, nor has the complete OSI
protocol stack been established. To make matters more confusing,
most of the middle-layer protocols on the market today do not
conform neatly to the OSI Model's network, transport and session
layers. They were created before the ISO started work on the
model.

The good news is many existing protocols are being incorporated
into the OSI Model. Where existing protocols are not
incorporated, interfaces between them and the OSI Model are being
implemented. This is the case for TCP/IP, NetBIOS and APPC, the
major middle-layer protocols available today.

In the PC LAN environment, NetBIOS is the most important
protocol. It stands for Network Basic Input/Output System. IBM
developed it as a BIOS for networks. It is essentially a Session
layer (Layer 5) protocol that acts as an applications interface
to the network. It provides the tools for a program to establish
a session with another program over the network. Hundreds of
programs have been written to this interface, making it the most
widespread protocol in the PC network arena.

NetBIOS does not obey the rules of the OSI Model in that it does
not talk only to the layers above and below it. As we said,
programs can talk directly to NetBIOS, skipping the application
and presentation layers. This doesn't keep NetBIOS from doing its
job. It just makes it incompatible with the OSI Model, which is
not the end of the world. Someone will write an interface between
the two, soon.

NetBIOS is limited to working on one network. Therefore, some
network vendors have established an interface between NetBIOS and
TCP/IP, a protocol from the Department of Defense for use over
large combinations of networks (internetworks).

TCP/IP stands for Transmission Control Protocol/Internet
Protocol. TCP is a Transport protocol (Layer 4), corresponding to
the definition we gave above. Its job is to get data from one
place to another without errors. It forms an interface between
the protocols above and below -- shielding the upper layers from
concern about the connection and the lower layers from concern
about transmission content.

The IP protocol is for getting data from one network to another.
Its main concern is bridging the differences between networks so
they don't have to be modified to talk to each other. It does
this by providing rules for the breakdown of data to conform with
a given network. Gateways, which are the physical translators
between networks, use IP's rules to take data from one network,
modify it and route it correctly over another network.

TCP/IP enjoys enormous support in government, scientific and
academic internetworks. These computers use UNIX and other
large-computer operating systems. In the past few years, business
internetworks have begun to approach the size of those in
government and universities. This has driven these businesses to
look for internetwork protocol standards. They have found TCP/IP
useful and it has become a de facto standard. Many see it as an
interim solution until the OSI transport and internetwork
protocols are finished. TCP/IP products for DOS-based networked
PCs are also available.

Often when TCP/IP is discussed, acronyms like SMTP, FTP and
TELNET are tossed around. These are applications that have been
written for TCP/IP and are widely used. They work at the
Applications layer (Layer 7). SMTP stands for Simple Mail
Transfer Protocol. FTP stands for File Transfer Protocol. TELNET
is the name for a terminal emulation protocol. These protocols,
written for TCP/IP, do exactly what they say they do.

Advanced Program-to-Program Communications, or APPC, is another
protocol for large networks. It comes from IBM and is part of Big
Blue's Systems Network Architecture (SNA). It is similar to
NetBIOS in that it provides an interface to the network for
programs so they may communicate, but it is not limited to one
network as is NetBIOS. APPC is geared toward mainframe computers,
though IBM is offering it as part of its OS/2 Extended Edition.

Using APPC, all computers communicate as peers, even PCs.
Previously in the IBM world, PCs were forced to emulate terminals
when communicating with mainframes. A number of other vendors,
mini and micro, also offer APPC.

APPC has received much publicity. Unfortunately, there are not
many applications for APPC in the PC network arena. There are
more in the minicomputer and mainframe network market.
Nevertheless, IBM and others are promoting APPC as a protocol
standard for the future. Its robustness, flexibility and
reliability make it worth the extra development effort.

There are other middle-layer protocols. XNS, IPX and NetBUEI are
all transport protocols. XNS is short for Xerox Network System.
It was one of the first local area network protocols used on a
wide basis, mainly for Ethernet (802.3) networks. 3Com and many
others use it. IPX is Novell's implementation of XNS. It is not
completely compatible with the original, but very widely used.
NetBUEI is IBM's transport protocol for its PC networking
products. All of these protocols perform similar tasks.

Many More
If it seems like the number of protocols is idiotic, it is and it
isn't. Different protocols have different advantages in different
environments. No single protocol stack will work better than
every other in every setting. NetBIOS seems to work fantastically
in small PC networks but is practically useless for communicating
with mainframes. APPC works well in mainframe environments.
TCP/IP excels in large internetworks.

On the other hand, much more is made about the differences in
protocols than is actually warranted. Proprietary protocols are
perfect solutions in many cases. Besides, if the proprietary
protocols are widespread enough, they become standards, and
gateways between them and other standards are built. This is
happening with some of the major protocols we have not covered.

These protocols include many de facto standards in minicomputer
and scientific workstation communications. They include DEC's
entire protocol suite, Sun Microsystems' NFS, AT&T's protocols
and many others. We have also left out Apple's AppleTalk and AFP.
While these enjoy widespread use, that use is based on the
computers these companies are selling and not the proliferation
of the protocols throughout the networking industry.

Unfortunately, whether proprietary or standard, users are still
faced with the dilemma of choice. This choice is made slightly
easier by the shakeout and standardization that has occurred over
the past few years at the lower Physical and Data Link layers.
There are three choices, Token Ring, Ethernet or Arcnet. Right
now, the same is happening at the higher layers. Can you guess
which way things will go? 

-- Aaron Brenner